A script is a sequence of commands that are to be interpreted, i.e., executed by a program running on a processor, as contrasted with a program that is compiled into machine code of a processor and then directly executed by a processor. Such a programmed processor that interprets a script is typically referred to as an interpreter. A script can be generated using a text editor. As an alternative, it is known to provide a graphical user interface (GUI) that permits a user to write a script by assembling commands and their arguments from pull-down menus. Such a GUI for scripting is typically referred to as a scriptor.
As an example, a script written in the Wireless Automation Manager Interface Language (WAMIL), that is the subject of a co-pending application, will be considered after a general discussion concerning wireless technology. The general discussion of wireless technology is presented to ensure an appreciation of the context of this script, and others, that will follow as well as a preferred use for the disclosed invention.
Large systems often include monitoring systems that permit one or more users to monitor the performance of the system in general, and to specifically monitor the state of one or more parameters of the large system. In some instances, the manner in which the monitoring system delivers information to the user can be a burden.
An example of the large system discussed above is a wireless communication network that provides wireless communications service to a wireless unit that is situated within a geographic region. A Mobile Switching Center (MSC) is responsible for, among other things, establishing and maintaining calls between wireless units and calls between a wireless unit and a wireline unit. As such, the MSC interconnects the wireless units and calls between a wireless unit and a wireline unit. As such, the MSC interconnects the wireless units within its geographic region with a public switched telephone network (PSTN). The geographic area serviced by the MSC is divided into spatially distinct areas called “cells.” In a schematic block diagram, each cell could be schematically represented by one hexagon in a honeycomb pattern. But, in practice, each cell has an irregular shape that depends on the topography of the terrain surrounding the cell. Typically, each cell contains a base station, which comprises the radios and antennas that the base station uses to communicate with the wireless units in the cell. The base stations also comprise the transmission equipment that the base station uses to communicate with the MSC in the geographic area via communication links. Cell coverage area may be broken up into sectors. One cell site may sometimes provide coverage for several sectors.
In a wireless cellular, communications system, a base station and a wireless. unit communicate voice and/or data over a forward link and a reverse link, wherein the forward link carries communication signals over at least one forward channel from the base station to the wireless unit and the reverse link carries communication signals on at least one reverse channel from the wireless unit to the base station. There are many different schemes for determining how wireless units and base stations communicate in a cellular communications system. For example, wireless communications links between the wireless units and the base stations can be defined according to different radio protocols, including time-division multiple access (TDMA), Frequency Division Multiple Access (FDMA), Code Division Multiple Access (CDMA) and others.
Within the geographic region, the MSC switches a call between base stations in real time as the wireless unit moves between cells, referred to as a handoff. Currently, in FDMA, TDMA, CDMA and GSM, cell site planning to determine the geographic coverage for a cell is manually intensive tasks that needs constant adjustment. In planning a cell, the topology of a geographic area and a suitable antenna site is selected based on availability and zoning rules. Such a selection is typically not optimal but adequate. Drive tests and manually collecting signaling data are then performed mostly on the perimeter of the coverage area. Transmit and receive antennas and power are then adjusted in a manually iterative manner to improve the call quality. Sometimes, frequencies are swapped with neighbor cells and/or transmit power is readjusted to improve the coverage. Over time, the cell site engineers review customer complaints and cell site dropped call reports and again try to manually optimize the RF performance.
Lucent Technologies Inc. has developed a monitoring system that a user can use to change parameters of the wireless communication system as well as to extract data about it. This monitoring system can generate the TIpdunix (TI) interface, the Status Display Page (SDP) interface and/or the AUTOPLEX Recent Change & Verification Database (AOXRCV) interface. These interfaces can be used individually. But typically, information extracted from one of the interfaces is used to make a decision to use a second one of the interfaces in one way or another. To use an interface, a user must start a discrete process. In a windows-based environment, each interface session has it own window.
Example SCRIPT No. 1, mentioned above, follows.
SCRIPT No. 1LineCommand01WAM:MSC 502WAM:CELL 12303WAM:BBA 804WAM:CONNECT TI05TI:op:cell 123, bba 806WAM:DISCONNECT TI07WAM:ENDTEST
Such a script as SCRIPT No. 1 gathers information about the BCR/BIU/ACU Trio No. 8, or BBA 8, located in cell No. 123 of mobile switching center No. 5 using the TI interface.
A technician in the field physically present at the cell 123 might desire the output of SCRIPT No. 11 as a starting point to servicing cell No. 123, particularly BBA No. 8, or might desire to run SCRIPT No. 1 to confirm a repair/adjustment that the technician has made.
If the technician could access a network where this script could be run by a server, then this would be very helpful to the technician. But hard-wired network connections are not typically provided at cell sites. So, as a practical matter, this tool is not available to the technician working at cell 123.
Alternatively, the technician could place a telephone call to a colleague present at a hard-wire network connection and request the colleague to run this script. But this would require the colleague to verbally relay the output of script No. 1. In some instances, the output is a simple numeric value or an indication of whether the tested component is active or idle. But in the great majority of instances, the output of such a script contains a great amount of data that is difficult, at best, to describe verbally over the telephone.
Now, assume that SCRIPT No. 1 was not present on the server or did not test/effect the exact component desired by the technician in the field. Again, at most, the technician could call his colleague, describe the desired script or modification to an existing script, and await his colleague's reply, assuming that the colleague could verbally describe the output of the test script.
All scripting languages are not particular to wireless technology, nor are all scripts written with a wireless communication network in mind. Suppose a script was written in an appropriate language for the banking industry. A technician physically present at an automated teller machine (ATM) in the field might wish to test a particular component in the ATM as part of the service procedure. That technician would encounter the same problems described above concerning a service procedure at the cell of the wireless network.